✨ Fiche d'Aide à la Décision

FAD

-

DOCUMENT D’ANALYSE FONCTIONNEL

-

FUNCTIONAL ANALYSIS DOCUMENT

Processus Achat

Microsoft Business Central

• 1. ANAL

Sommaire

1. Introduction 3

2. Vue d‘ensemble 4

3. Planification 5

4. Traitement d‘une livraison directe 6

5. Saisie d’une demande de prix 7

6. Saisie d’une commande cadre 8

7. Saisie d’une commande d‘achat 10

8. Saisie d’un retour d’une commande achat 12

9. Rapports achat 13

10. Historique achat 14

11. Annexe 1 : Liste d‘écarts 16

1. Introduction

Ce document liste l’analyse fonctionnel sur les processus métier du client concernant le domaine des achats. Les principaux objectifs de l’analyse fonctionnel sont :

• Visiter les sites clients comme les usines, entrepôts et/ou bureaux
• Conduire des ateliers orientés processus.
• Ne pas rentrer en profondeur sur les fonctionnalités de l’ERP ni faire de démonstrations
• Comprendre la façon de travailler actuelle, les points faibles et les attentes globales et futures
• Identifier les écarts critiques et les interfaces qui peuvent avoir un impact sur le projet
• Identifier les volumes des référentiels et données transactionnelles
• Confirmer le périmètre fonctionnel, technique, géographique et organisationnel du projet
• Identifier un jeu de donnée nécessaire pour l’ERP pour mieux préparer les ateliers de démonstration.

Ce document a été préparé sur la base d‘atelier(s) réalisés avec les membres de l'équipe de projet suivants :

Versions du document

Liste de diffusion

1. Vue d‘ensemble
   1. Schéma d’ensemble des processus achat

Les processus standards ERP qui font partie des ateliers d’analyse sur les achats sont :

3 Planification

3.1. Contexte et Hypothèses

**3.1 Contexte et Hypothèses**

Le processus d'achat du client est basé sur un atelier achats qui gère les besoins des projets, des achats génériques de la société et des achats mutualisés multi-projet. Les besoins des projets sont anticipés ou constatés et sont traités au niveau de chaque projet. Le processus inclut la conception détaillée de pièces spécifiques optimisées, la consommation de pièces standard du stock complété par achat des pièces nécessaires au-delà du stock.

La chaîne d'approbation est basée sur un seuil dépendant de la personne qui passe la commande ou du risque sur la commande. Le critère d'approbation est l'achat dans le budget ou pas.

Les fonctionnalités souhaitées dans le système incluent le suivi de la confirmation de commande fournisseur, la date de livraison renseignée dans le système, l'intégration des coûts de transport liés à la commande et la prise en compte des différents plannings (fournisseur, transport, spécialité).

Les hypothèses retenues incluent la nécessité de mettre en place un flux d'approbation formalisé, la prise en compte des différents plannings et la gestion des coûts de transport liés à la commande. Les informations manquantes incluent les détails du processus d'inspection qualité et les critères de validation de la réception.

En résumé, le processus d'achat du client est basé sur un atelier achats qui gère les besoins des projets, des achats génériques de la société et des achats mutualisés multi-projet. Les fonctionnalités souhaitées dans le système incluent le suivi de la confirmation de commande fournisseur, la date de livraison renseignée dans le système et l'intégration des coûts de transport liés à la commande.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

3.2. Schéma des processus ERP : Planification 1.0

3.3. Principales règles de gestion

- La pièce ne peut être marquée "réceptionnée" que **après validation qualité (incoming inspection)**.
- Toute pièce ALM DES doit être étiquetée avec : numéro de projet, référence article, et numéro de série unique généré par le système.
- Les pièces standards (STC, COT) sont stockées dans le "stock général", tandis que les pièces projet vont dans un emplacement dédié au projet.
- La sur-réception (ex. 5 pièces reçues pour un besoin de 2) génère automatiquement un surplus affecté au stock projet ou général selon la codification.
- Le "fichier article" doit être paramétré pour prendre en compte les différents types d'articles (en stock, non inventory, service).
- Les "demandes d'achat" doivent être liées à un "numéro de projet" pour assurer la traçabilité.
- Les "devis" doivent être renseignés avec les informations pertinentes (due date, requested receipt date, etc.).
- Les "commandes" doivent être liées à un "numéro de projet" et doivent prendre en compte les différents plannings (fournisseur, transport, etc.).
- Le "contrôle qualité" doit être effectué avant de marquer la pièce "réceptionnée" et doit être validé par le responsable qualité.
- Les "lignes budget" doivent être remplies pour remonter le coût budgété ou le montant réel dans la commande.
- Les "dates de planification" doivent être renseignées dans les lignes projet pour permettre la consommation sur le projet.

3.4. Documents et statistiques

**Planification**

**3.4. Documents et statistiques**

Le processus de planification comprend la gestion des besoins projet, la création de devis et la passation de commandes. Les documents clés dans ce processus sont :

* Fiche article : permet de gérer les articles en stock, non en stock et services.
* Journal des achats : permet de suivre les commandes et les livraisons.
* Workflow validation : permet de formaliser le flux d'approbation pour les commandes.

Les statistiques importantes à suivre incluent :

* Lead-time : temps nécessaire pour obtenir les fournitures.
* Stock de sécurité : quantité minimale de stock à maintenir.
* Minimum Order Quantity : quantité minimale à commander pour bénéficier d'un rabais.

Les documents à joindre à la demande de devis incluent :

* Documentation technique.
* Spécifications des produits.

Les champs à renseigner sur les lignes de commande incluent :

* Due Date : date de livraison.
* Requested Receipt Date : date de réception attendue.
* Numéro de projet : permet de lier la commande au projet.
* Tâches projet : permet de consommer les ressources sur le projet.

La réception des livraisons est suivie par un document de contrôle qualité, qui inclut des photos, un tracking lot et série, et une validation par le responsable qualité.

3.5. Volume des données

Planification

Le processus de planification comprend plusieurs étapes clés pour gérer les achats et les projets.

Volume des données

Le volume des données est géré à travers plusieurs tableaux de bord adaptés au profil de l'utilisateur. Le tableau de bord permet d'accéder aux informations pertinentes en temps réel. Il est possible d'exporter les données vers Excel pour une analyse plus approfondie.

Les données sont classées en trois types d'articles : en stock, non-inventoriel (sans gestion de stock) et service. La gestion du multi-sourcing est également possible, y compris la référence fournisseur. Les informations de planning, telles que le lead-time, le stock de sécurité et le Minimum Order Quantity, sont également prises en compte.

Les "purchase quote" (demandes d'offre) sont rentrées avec le numéro de projet pour assurer le lien avec la commande et le projet. Les offres fournisseurs sont ensuite transformées en commandes en 1 clic. La gestion de l'incoterm est également possible pour suivre les dates d'expédition.

La gestion des projets est également possible avec des Work-Packages, des dates, des quantités et des budgets. Les documents de réception sont créés pour suivre les lots et les séries. Le contrôle qualité est également possible avec la création d'un document de contrôle qualité avec rattachement de photos.

3.6. Écarts critiques et interfaces

**Écarts critiques et interfaces**

Les écarts majeurs entre le processus actuel du client et les bonnes pratiques ou les exigences cibles du projet sont les suivants :

* **Contrôle qualité** : le processus actuel ne prévoit pas d'inspection systématique à la réception, tandis que l'objectif est de mettre en place un flux d'approbation formalisé.
* **Suivi de la confirmation de commande fournisseur** : la fonctionnalité est actuellement inexistant dans le système.
* **Date de livraison renseignée dans le système** : la date de livraison n'est pas renseignée dans le système actuel.
* **Intégration des coûts de transport lié à la commande** : la fonctionnalité est actuellement inexistant dans le système.
* **Gestion des certificats** : les certificats ne sont pas gérés systématiquement pour toutes les commandes.
* **Numéro de projet obligatoire sur le devis** : le numéro de projet n'est pas obligatoire sur le devis actuel.
* **Documentation à joindre à la demande de devis** : la documentation à joindre à la demande de devis n'est pas précisée.
* **Utilisation des champs** : les champs "Due Date" et "Requested Receipt Date" ne sont pas utilisés dans le système actuel.
* **Gestion des Incoterms** : la gestion des Incoterms n'est pas précisée dans le système actuel.
* **Partie shipping** : la partie shipping n'est pas détaillée dans le système actuel.
* **Contrôle qualité** : le processus détaillé d'inspection n'est pas défini avec le responsable qualité.

Les interfaces nécessaires entre le système cible et les autres applications, services ou départements impactés sont les suivantes :

* **Atelier de migration** : un atelier sur la stratégie de migration doit être organisé pour discuter de l'histoire.
* **Gestion des projets** : la gestion des projets, y compris les Work-Packages, avec dates, quantités et budget, doit être intégrée dans le système.
* **Qualité Contrôle** : la gestion des certificats et la validation du processus de contrôle qualité doivent être intégrées dans le système.
* **Fournisseurs** : la gestion des fournisseurs, y compris les références fournisseur et les plannings, doit être intégrée dans le système.
* **Transporteurs** : la gestion des transporteurs et les plannings doivent être intégrés dans le système.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

4 Traitement d‘une livraison directe

4.1. Contexte et Hypothèses

Traitement d'une livraison directe

Contexte et hypothèses :

Le client utilise Microsoft Dynamics 365 Business Central pour gérer ses achats et ses projets. Les besoins des projets sont anticipés ou constatés, et des achats sont passés au niveau de chaque projet. Les achats sont classés en trois types : spécifiques optimisés, standard et non-inventoriables. Le processus de livraison directe implique la réception de colis avec des pièces, qui sont ensuite contrôlées et validées par la qualité.

Les hypothèses retenues pour ce processus sont :

* Les instructions d'incoming sont données par le chef de projet.
* Les certificats sont gérés par la qualité contrôle.
* Les pièces VOL sont livrées avec des certificats.
* Les lieux de stockage sont Payerne.
* Le suivi des lead times fournisseurs est effectué.
* Les différents plannings (fournisseur, transport, spécialité) sont pris en compte.
* Le numéro de projet est obligatoire sur le devis pour lier la commande au projet.
* La documentation est jointe à la demande de devis.
* Les champs Due Date et Requested Receipt Date sont utilisés.

Les difficultés actuelles sont :

* Pas de document d'entrée en stock.
* Difficulté pour le chef de projet pour contrôler les colis reçus.

Les attentes exprimées sont :

* Mettre en place un flux d'approbation formalisé.
* Suivre la confirmation de commande fournisseur.
* Date de livraison renseignée dans le système.
* Intégration des coûts de transport lié à la commande.
* Chaque colis reçu est pris en photo.
* Lorsqu'un colis arrive, il n'est pas toujours clair à qui il est destiné.
* Le Chef de Projet (CP) donne l'instruction de faire un contrôle qualité léger ou approfondi.
* L'ingénieur ou le CP discute directement avec le fournisseur en cas de non-conformité.
* Facture non payée tant que la non-conformité n'est pas résolue.
* Certains fournisseurs demandent des acomptes.
* À la réception, l'atelier scanne les documents avec la pièce pour assurer la traçabilité.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

4.2. Schéma des processus ERP : Traitement d’une livraison directe 2.0

4.3. Principales règles de gestion

- La pièce ne peut être marquée "réceptionnée" que **après validation qualité (incoming inspection)**.
- Toute pièce ALM DES doit être étiquetée avec : numéro de projet, référence article, et numéro de série unique généré par le système.
- Les pièces standards (STC, COT) sont stockées dans le "stock général", tandis que les pièces projet vont dans un emplacement dédié au projet.
- La sur-réception (ex. 5 pièces reçues pour un besoin de 2) génère automatiquement un surplus affecté au stock projet ou général selon la codification.
- Le "Warehouse receipt" est créé pour suivre les lots et les pièces reçues. La qualité doit valider le processus avant de marquer la pièce comme "réceptionnée".
- Les certificats sont gérés par la Qualité Contrôle.
- Les photos des colis sont prises avant et après ouverture.
- Les Non Conformités (NC) sont traitées avec le fournisseur et peuvent entraîner un paiement en avance.
- Les pièces VOL sont livrées avec des certificats.
- Les lieux de stockage sont Payerne.
- Les lead times fournisseurs sont suivis.
- Les différents plannings (fournisseur, transport, spécialité) sont pris en compte.
- Le numéro de projet est obligatoire sur le devis pour lier la commande au projet.
- La documentation est jointe à la demande de devis.
- Les champs "Due Date" et "Requested Receipt Date" sont utilisés.
- Le devis est lié à la commande.
- Les Incoterms sont gérés avec le champ "Shipment Method Code".
- Le numéro de projet et les tâches projet sont renseignés sur les lignes pour permettre la consommation sur le projet.
- La réception est détaillée avec quantité et rattachement à la commande.
- Le contrôle qualité est créé avec rattachement de photos, tracking lot et série.
- La validation de la réception est effectuée par le responsable qualité.
- Le processus d'inspection est défini avec le responsable qualité.
- Les lignes budget ont des champs pour remonter le coût budgété ou le montant réel dans la commande.
- Les dates de planification sont renseignées dans les lignes projet.

4.4. Documents et statistiques

Générer les documents ERP nécessaires pour le traitement d'une livraison directe implique plusieurs étapes et documents. Voici les documents et statistiques nécessaires :

- **Fiche article** : mise à jour de la quantité en stock et des informations de gestion de stock.
- **Journal des achats** : enregistrement de la commande et de la livraison.
- **Document de réception** : création d'un document de réception pour valider la livraison.
- **Contrôle qualité** : création d'un document de contrôle qualité avec rattachement de photos et tracking lot et série.
- **Facture** : génération de la facture après validation de la réception et du contrôle qualité.

Les états ou statistiques nécessaires pour le suivi du processus incluent :

- **Tableau de bord** : mise à jour en temps réel des informations de gestion de stock, des commandes et des livraisons.
- **Statistiques de stock** : suivi de la quantité en stock et des informations de gestion de stock.
- **Statistiques de commandes** : suivi des commandes et des livraisons.
- **Statistiques de contrôle qualité** : suivi des contrôles qualité et des résultats.

Il est important de noter que ces documents et statistiques nécessitent une mise à jour régulière pour garantir l'exactitude et la fiabilité des informations.

4.5. Volume des données

Traitement d'une livraison directe

**Volume des données**

- Données référentielles : les fiches articles (en stock, non inventory, service), les fournisseurs, les incoterms, les plannings fournisseurs et transporteurs.
- Nombre de documents ou transactions générés par période :
+ Demande de devis : 1 document par projet.
+ Demande d'offre : 1 document par projet.
+ Commande (Make Order) : 1 document par projet.
+ Réception : 1 document par série, 1 document par lot, 1 document par commande.
+ Contrôle qualité : 1 document par série, 1 document par lot, 1 document par commande.
+ Facture : [INFORMATION MANQUANTE]
- Fréquence de génération des documents :
+ Demande de devis : [INFORMATION MANQUANTE]
+ Demande d'offre : [INFORMATION MANQUANTE]
+ Commande (Make Order) : [INFORMATION MANQUANTE]
+ Réception : [INFORMATION MANQUANTE]
+ Contrôle qualité : [INFORMATION MANQUANTE]
+ Facture : [INFORMATION MANQUANTE]

Il est important de noter que les volumes de données peuvent varier en fonction de la fréquence des commandes et des livraisons. Il est donc nécessaire de surveiller régulièrement les données pour ajuster les processus et les paramètres du système de gestion de la chaîne d'approvisionnement.

4.6. Écarts critiques et interfaces

**Traitement d'une livraison directe**

**Écarts critiques et interfaces**

Voici les écarts majeurs entre le processus actuel et le modèle cible :

* **Contrôle qualité** : Actuellement, pas de document d'entrée en stock, ce qui peut entraîner des difficultés pour le chef de projet. Un document de contrôle qualité doit être créé avec rattachement de photos et tracking lot et série.
* **Réception** : La quantité et le rattachement à la commande doivent être renseignés. Un document de réception doit être créé avec les informations pertinentes.
* **Gestion des coûts** : Les coûts de transport liés à la commande doivent être intégrés dans le système.
* **Suivi des lead times fournisseurs** : Les lead times fournisseurs doivent être suivis pour planifier les livraisons.
* **Gestion des Incoterms** : Les Incoterms doivent être gérés pour déterminer les responsabilités de la livraison.
* **Numéro de projet obligatoire** : Le numéro de projet doit être obligatoire sur le devis pour lier la commande au projet.
* **Documentation à joindre** : La documentation à joindre à la demande de devis doit être définie.
* **Utilisation des champs** : Les champs Due Date et Requested Receipt Date doivent être utilisés pour planifier les livraisons.

**Interfaces nécessaires** :

* **Système de gestion de projet** : Un système de gestion de projet doit être intégré pour gérer les projets et les commandes.
* **Système de gestion de stock** : Un système de gestion de stock doit être intégré pour gérer les stocks et les livraisons.
* **Système de gestion de qualité** : Un système de gestion de qualité doit être intégré pour gérer les contrôles qualité et les réceptions.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

1. Saisie d’une demande de prix

5.1. Contexte et Hypothèses

Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

• 1. Schéma des processus ERP : Demande de prix 3.0

5.3. Principales règles de gestion

Décrire les principales règles du client et comment l’ERP peut y répondre.

5.4. Documents et statistiques

Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.

5.5. Volume des données

Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).

5.6. Écarts critiques et interfaces

Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

6 Saisie d’une commande cadre

6.1. Contexte et Hypothèses

Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

6,2, Schéma des processus ERP : Saisie d’une commande cadre 4.0

6.3. Schéma des processus ERP : Saisie d’une commande d’achat

6.4. Principales règles de gestion

Décrire les principales règles du client et comment l’ERP peut y répondre.

6.5. Documents et statistiques

Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.

6.6. Volume des données

Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).

6.7. Écarts critiques et interfaces

Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse (après la phase d'Analyse fonctionnel).

7 Saisie d’une commande d‘achat

7.1. Contexte et Hypothèses

Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

7.2 Schéma des processus ERP : Saisie d’une commande d’achat

7.3. Principales règles de gestion

Décrire les principales règles du client et comment l’ERP peut y répondre.

7.4. Documents et statistiques

Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.

7.5. Volume des données

Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).

7.6. Écarts critiques et interfaces

Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse (après la phase d'Analyse fonctionnel).

8 Saisie d’un retour d’une commande achat

8.1. Contexte et Hypothèses

Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

8.2. Schéma des processus ERP : Saisie d’un retour d’une commande achat 6.0

8.3. Principales règles de gestion

Décrire les principales règles du client et comment l’ERP peut y répondre.

8.4. Documents et statistiques

Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.

8.5. Volume des données

Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).

8.6. Écarts critiques et interfaces

Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

9 Rapports achat

9.1. Contexte et Hypothèses

Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

9.2 Schéma des processus ERP : Rapport achat 8.0

9.3. Principales règles de gestion

Décrire les principales règles du client et comment l’ERP peut y répondre.

9.4. Documents et statistiques

Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.

9.5. Volume des données

Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).

9.6. Ecarts critiques et interfaces

Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

10 Historique achat

10.1. Contexte et Hypothèses

Décrire la situation actuelle, les points critiques et les attentes client sur ce processus.

Les hypothèses qui peuvent avoir un impact sur le projet doivent être indiquées.

10.2 Schéma des processus ERP : Historique achat 9.0

10.3. Principales règles de gestion

Décrire les principales règles du client et comment l’ERP peut y répondre.

10.4. Documents et statistiques

Décrire les documents de l’ERP qui doivent être imprimés durant ce processus ainsi que les états et statistiques métiers attendus.

10.5. Volume des données

Indiquer les volumes des données référentielles ainsi que le nombre de documents par période (jour, semaine, mois ou années).

10.6. Écarts critiques et interfaces

Indiquer les écarts critiques et interfaces identifiés durant ces ateliers d’analyse.

Ces écarts et interfaces doivent être initialisés dans la liste des écarts délivrée qui doit être finie à la fin de la phase d’Analyse.

11 Annexe 1 : Liste d‘écarts

11.1. Liste d’écarts

La liste d’écart doit être initialisée et finalisée à la fin de la phase d’analyse.

Indiquer l’URL où la liste des écarts sera stockée (SharePoint / Teams / DevOps / Autre).